As stated above, the present invention relates to a method for updating a routing entry for a communication partner node communicating with a communication originating node via a network containing at least one routing node.
In this connection, it is to be noted that the present invention is not limited to a specific network type, but may be applied to any network type allowing a communication partner node to communicating with a communication originating node via at least one routing node. For example, the invention is applicable to a communication network operated on the basis of the Internet Protocol IP, irrespective of the version of the Internet protocol, i.e. whether it is IPv4 or IPv6. Also, the present invention is applicable in case the communication nodes (originating and partner node) are fixed nodes and/or mobile nodes which can be freely connected at an arbitrary access point to the network. The type of connection, i.e. whether wirebound or wireless also does not matter for the purpose of the present invention. In case of a wireless network access and assuming an IP based network, then for example the so-called Mobile IP MIP protocol is used (MIPv4 or MIPv6). Nevertheless, other IP protocol versions or even other protocol types may be used.
In order to illustrate and explain the present invention, however, the subsequent description—without any limitation of the scope of the invention—will focus on a case in which at least the communication originating nodes are mobile nodes and the protocol used for communication is MIPv6.
Thus, with reference to the terminology used in the present invention as compared to the MIPv6 specifications, it will be evident to a skilled reader that a communication originating node will correspond to a mobile node MN, a communication partner node will correspond to a correspondent node CN, a routing node will correspond to a home agent HA (of the mobile node MN), and the routing entry to be updated will correspond to a binding cache at the correspondent node CN. Nevertheless, the present invention is not restricted to updating a routing entry at the communication partner node but it is to be noted that the routing entry can be physically separated from the communication partner node which remotely accesses the routing entry, so that the routing entry for the communication partner node is concerned.
In case of mobile nodes enabled to access the network at different access points, the communication originating node/mobile node MN is identified by a fixed address also known as home address HoA and a variable address known as care_of_address CoA. The fixed address does not change but rather identifies the node (“logical location”), while the variable address changes depending on the access point of the network (e.g. after the mobile node MN roamed within the network) and corresponds a “physical location” to which messages destined for the mobile node are to be delivered.
Thus, as mentioned earlier, the present invention is related to Mobile IPv6, and more particularly is concerned with a method to securely update a routing entry for a communication partner node, i.e. to secure transmission of Binding Update messages and the binding cache for the communication partner node. The invention thus belongs to the same field as the Return Routability mechanism defined in Mobile IP, with which skilled persons are expected to be familiar, so that a description thereof is omitted here but the skilled reader is referred to Mobile IP definitions.
In more detail, this invention addresses the issues described in the IETF draft “Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6” by Allison Mankin, Basavaraj Patil, Dan Harkins, Erik Nordmark, Pekka Nikander, Phil Roberts and Thomas Narten, dated Nov. 5, 2001 and published and/or to be retrieved via www.ietf.org/proceedings/02mar/I-D/draft-ietf-mobileip-mipv6-scrty-reqts-02.txt.
To summarize the issue, in Mobile IPv6, the correspondent node CN should only accept Binding update messages (BU's) from valid mobile nodes MN, i.e. the MN that actually owns the care of address CoA sent in the Binding Update message; otherwise, an intruder or malicious node may modify the binding cache for and/or in the CN corresponding to the MN leading to several types of attacks such as those know for example as “man in the middle”, “reflection”, “bombing” and “denial of service” attacks (e.g. by changing the content of the binding cache in the CN from the current care of address CoA to a different address, the CN will start sending the packets to the new address and the MN will not receive them anymore).
The current Mobile IPv6 specifications mandate the Return Routability (RR) test to prevent the above mentioned identified attacks, but the security of this protocol strongly relies on the confidentiality of the home cookie sent from the CN to the MN via its home agent HA. To make sure that intruders cannot learn its value (which will allow them to send fake binding update message and update the binding cache for/at the CN), the MIPv6 specifications strongly recommend that the Encapsulation Security Protocol (ESP) should be applied between the MN and its HA. An encrypted tunnel applied between these two nodes will allow a secure transmission of the home cookie.
This assumption is, however, valid only in some environments. However, when the MN is attached to a network protected by firewalls, firewalls need to be able to filter the packets based on the source IP address, the destination IP address, the next header, the port numbers and eventually other fields/parameters (to prevent e.g. intruders to user Finger, NFS, or perform DNS (DNS: Domain Name Sever) zone transfer, TCP SYN Flood, etc.). ESP can not be applied: In such cases the firewalls will in fact have to drop all these packets since due to the application of ESP, the firewall is not capable to verify e.g. the values in the TCP header (TCP: Transmission Control Protocol). Therefore the MN won't be able to securely send any binding update BU messages.
To protect the binding update messages, two solutions have previously been proposed:
1) The Return Routability (RR) test which is defined in the Mobile IPv6 specifications and mandatory; but as described previously, this protocol is not applicable in environments with firewalls (i.e. not applicable in most networks).
2) The “CGA” proposal, also called “sucv”. However this solution relies on public keys and public keys operations may be an issue for mobile nodes: they may not have the necessary computational capabilities to perform the required digital signatures and other required operations. That is why RR has been adopted in the MIPv6 specifications
Thus, as explained before and summarizing, in Mobile IPv6, the correspondent node (CN) should only accept Binding update BU messages from a valid Mobile Node (MN). The current Mobile IPv6 specifications mandate the Return Routability (RR) test to prevent identified attacks, but the security of this protocol strongly relies on the confidentiality of the home cookie sent from the CN to the MN via its home agent HA. To make sure that intruders cannot learn its value (which will allow them to send fake binding update message and update the binding cache at the CN), the IPSec Encapsulation Security Protocol (ESP) mode should be applied between the MN and its HA. An encrypted tunnel applied between these two nodes allows a secure transmission of the home cookie. However if the MN is attached to a network protected by firewalls, firewalls need to be able to filter the packets based on the source IP address, the destination IP address, the next header, the port numbers and eventually other fields/parameters ESP can not be applied and the firewalls will have to drop these packets since due to the application of ESP, the firewall is not capable to verify e.g. the values in the TCP header. Therefore the MN won't be able to securely send any BU messages.